With the ever-increasing integration of electronic devices in people's lives, users often use multiple types of electronic gadgets for use in everyday activities. For example, it is not uncommon for users to have a personal computer (e.g., a laptop) for work purposes, a smart phone (e.g., an iPhone®) for mobile connectivity, a set-top box connected to a digital television for home-entertainment purposes, etc. It is also not uncommon for such gadgets to render similar applications (e.g., streaming an online video clip). In typical instances, the user may have a number of these gadgets connected via a common network (e.g., a home wireless network). In such instances, the user may wish to switch rendering of an application from one mobile device to another for a variety of reasons.
Consider an illustrative scenario. A user, while walking from his car to his office is watching a video clip on his smart phone to prepare for a meeting. The video clip is streamed into his smart phone via the Internet from a remote server. As soon as the user enters his office, he may want to switch the video from the smart phone to his office computer to be able to view the video on a larger display screen. Typically, the format (e.g., the type of encoding) of the video streamed from the server to the device would depend on the type of device. For example, a video clip rendered to an iPhone device may need to be encoded according to H.264 standards. However, when the video rendering is switched from an iPhone to a laptop, the server may instead need to supply the video clip that is formatted according to, for example, Windows Media Video standards.
In typical scenarios, the server may not readily have a copy of the video file in the requested (i.e., the second) format. Accordingly, the server would have to encode or otherwise reformat the video data prior to streaming the video clip to the second client device, introducing substantial latency in the rendering of the video. Such data processing latency problems are only exacerbated when the application (e.g., the video clip) is converted on a remote server and streamed to the client device. In such cases, network latency and data processing latency both contribute to the inability of the client to deliver seamless rendering of the application.
Some prior art systems attempt to resolve this issue by retaining at least popularly requested content in several formats. This results in content providers having to increase their storage footprint to be able to handle storage of all the application content, increasing the cost of maintaining and delivering the content. Also, without knowing what type of application format will be required, the content providers would need to maintain a separate copy for every potential format of the application, further increasing the cost of storage. It would be preferable to deliver the content just-in-time, that is, when the data is requested by a client device. However, present systems suffer from the latency issues illustrated above when attempting to perform just-in-time transcoding.